Software-defined networking is an emerging architecture for data transfer networks. In a software-defined network “SDN”, the control plane is separated from the data plane so that the control plane is implemented in one or more controllers that can be separate from the network elements and the data plane is implemented in the network elements. The network elements can be, for example, Internet Protocol “IP” routers, multiprotocol label switching “MPLS” nodes, packet optical switches, and/or Ethernet switches. Each network element may consist of a single apparatus or a combination of a plurality of apparatuses. Typically, the software-defined networking allows for quick experimenting and optimization of switching and/or routing policies and external access to the innards of network elements that formerly were closed and proprietary.
The one or more controllers of the software-defined network “SDN” are adapted to configure the network elements so that the network elements are capable of operating as nodes of the software-defined network. When configuring a network element, the controller sends to the network element configuration data with the aid of which the network element constructs a programmable data path for forwarding data. The programmable data path comprises one or more look-up tables with the aid of which the network element is capable of operating as a part of the software-defined network. The software-defined data path can be constructed in accordance with for example the OpenFlow protocol or the Forwarding and Control Element Separation “ForCES” protocol. More details about the OpenFlow can be found from the OpenFlow Switch Specification managed by the Open Networking Foundation “ONF”, and more details about the ForCES can be found from the Request for Comments “RFC”: 3746 “Forwarding and Control Element Separation”, the Internet Engineering Task Force “IETF”, Network Working Group.
In many cases there is, however, a need for hybrid network elements where both the above-presented programmable data path based on the software-defined networking and a traditional fixed-functionality data path are maintained for forwarding data. The fixed-functionality data path can support for example one or more Open Systems Interconnection “OSI” model Level 3 “L3” network layer protocols, one or more OSI L2 data link layer protocols, and/or the MultiProtocol Label Switching “MPLS” protocol. The one or more L3 network layer routing protocols may comprise for example the Internet Protocol “IP”, and the one or more L2 data link layer switching protocols may comprise for example the Ethernet protocol. The fixed functionality data path may comprise for example an Internet protocol forwarding table, an Access Control List “ACL” filter, and other entities for fixed-functionality actions.
Hybrid network elements of the kind described above are, however, not free from challenges. One of the challenges is related to a need to switch from the programmable data path to the fixed-functionality data path and vice versa in situations where data being managed is first managed in one of the above-mentioned data paths and then it turns out that functionality provided by the other one of the data paths is needed for further actions related to the data under consideration. In traditional hybrid network elements, the transfer from the programmable data path to the fixed-functionality data path is accomplished by switching from the end of the programmable data path to the beginning of the fixed-functionality data path. The switching always to the beginning of the fixed-functionality data path loads the network processing unit “NPU” and/or other hardware for implementing the fixed-functionality data path. Switching in the opposite direction from the fixed-functionality data path to the programmable data path is typically not supported.